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PREFACE 


This  development  specification  covers  the  work  performed 
under  Air  Force  Contract  F33615-80-C-5155  ( ICAM  Project  6201). 
This  contract  is  sponsored  by  the  Materials  Laboratory.  Air 
Force  Systems  Command.  Wright-Patterson  Air  Force  Base.  Ohio. 

It  was  administered  under  the  technical  direction  of  Mr.  Gerald 
C.  Shumaker.  ICAM  Program  Manager,  Manufactur ing  Technology 
Division,  through  Project  Manager,  Mr.  David  Judson.  The  Prime 
Contractor  was  Production  Resources  Consulting  of  the  General 
Electric  Company,  Schenectady,  New  York,  under  the  direction  of 
Mr.  Alan  Rubens te in.  The  General  Electric  Project  Manager  was 
Mr.  Myron  Hurlbut  of  I'dustrial  Automation  Systems  Department, 
Albany,  New  York. 

Certain  work  aimed  at  improving  Test  Bed  Technology  has 
been  performed  by  other  contracts  with  Project  6201  performing 
integrating  functions.  This  work  consisted  of  enhancements  to 
Test  Bed  software  and  establishment  and  operation  of  Test  Bed 
hardware  and  communications  for  developers  and  other  users. 
Documentation  relating  to  the  Test  Bed  from  all  of  these 
contractors  and  projects  have  been  integrated  under  Project  6201 
for  publication  and  treatment  as  an  integrated  set  of  documents. 
The  particular  contributors  to  each  document  are  noted  on  the 
Report  Documentation  Page  (DD1473).  A  listing  and  description 
of  the  entire  project  documentation  system  and  how  they  are 
related  is  contained  in  document  FTR620100001 ,  Project  Overview. 

The  subcontractors  and  their  contributing  activities  were 
as  follows: 


TASK  4-2 

Subcontractors 

Boeing  Military  Aircraft 
Company  ( BMAC ) 

D  Appleton  Company 
( DACOM ) 


General  Dynamics/ 
Ft  Worth 


Role 

Reviewer . 


Responsible  for  IDEF  support, 
state-of-the-art  literature 
search . 

Responsible  for  factory  view 
function  and  information 
mode  1  s 
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Subcontractors 

Illinois  Institute  of 
Technology 

North  American  Rockwell 
Northrop  Corporation 

Pritsker  and  Associates 
SofTech 


Role 

Responsible  for  factory  view 
function  research  (IITRI) 
and  information  models  of 
small  and  medium-size  business. 

Reviewer . 

Responsible  for  factory  view 
function  and  information 
models . 

Responsible  for  IDEF2  support. 
Responsible  for  IDEFO  support. 


TASKS  4.5  -  4.9  (TEST  BED) 
Subcontractors  Role 


Boeing  Military  Aircraft 
Company  ( BMAC ) 


Computer  Technology 
Associates  (CTA ) 


Control  Data  Corporation 
(  CDC  ) 


Responsible  for  consultation  on 
applications  of  the  technology 
and  on  IBM  computer  technology. 

Assisted  in  the  areas  of 
communications  systems,  system 
design  and  integration 
methodology,  and  design  of  the 
Network  Transaction  Manager. 

Responsible  for  the  Common  Data 
Model  (CDM)  implementation  and 
part  of  the  CDM  design  (shared 
with  DACOM) . 


D.  Appleton  Company 
( DACOM ) 


Responsible  for  the  overall  CDM 
Subsystem  design  integration 
and  test  plan,  as  well  as  part 
of  the  design  of  the  CDM 
(shared  with  CDC).  DACOM  also 
developed  the  Integration 
Methodology  and  did  the  schema 
mappings  for  the  Application 
Subsystems . 


i  v 
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Subcontractors 


Digital  Equipment 
Corporation  (DEC) 


McDonne 1 1  Doug 1 as 
Automation  Company 
(McAuto) 


On-Line  Software 
International  (OSI) 


Role 

Consulting  and  support  of  the 
performance  testing  and  on  DEC 
software  and  computer  systems 
operation. 

Responsible  for  the  support  and 
enhancements  to  the  Network 
Transaction  Manager  Subsystem 
during  1984/1985  period. 

Responsible  for  programming  the 
Communications  Subsystem  on  the 
IBM  and  for  consulting  on  the 
IBM. 


Rath  and  Strong  Systems 
Products  (RSSP)  (In  1985 
became  McCormack  &  Dodge) 


SofTech ,  Inc . 


Software  Performance 
Engineering  (SPE) 


Structural  Dynamics 
Research  Corporation 
( SDRC ) 


Responsible  for  assistance  in 
the  implementation  and  use  of 
the  MRP  II  package  (PIOS)  that 
they  supplied. 

Responsible  for  the  design  and 
implementation  of  the  Network 
Transaction  Manager  (NTM)  in 
1981/1984  period. 

Responsible  for  directing  the 
work  on  performance  evaluation 
and  analysis. 

Responsible  for  the  User 
Interface  and  Virtual  Terminal 
Interface  Subsystems . 


Other  prime  contractors  under  other  projects  who  have 
contributed  to  Test  Bed  Technology,  their  contributing 
activities  and  responsible  projects  are  as  follows: 


Contractors 


ICAM  Project  Contributing  Activities 


Boeing  Military 
Aircraft  Company 

( BMAC ) 


1701 ,  2201 ,  Enhancements  for  IBM 
2202  node  use.  Technology 

Transfer  to  Integrated 
Sheet  Metal  Center 
( I SMC ) . 
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Contractors 

ICAM  Project 

Contributing  Activities 

Control  Data 
Corporation  (CDC) 

1502,  1701 

IZSS  enhancements  to 
Common  Data  Model 
Processor  (CDMP). 

D.  Appleton  Company 
(DACOM) 

1502 

IISS  enhancements  to 
Integration  Methodology 

General  Electric 

1502 

Operation  of  the  Test 
Bed  and  communications 
equipment . 

Hughes  Aircraft 

Company  (HAC) 

1701 

Test  Bed  enhancements. 

Structural  Dynamics 
Research  Corporation 
(SDRC) 

1502,  1701, 
1703 

IISS  enhancements  to 
User  Interface/Virtual 
Terminal  Interface 
(UI/VTI ) . 

Systran 

1502 

Test  Bed  enhancements . 
Operation  of  Test  Bed. 
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SECTION  1 
SCOPE 


1 . 1  Ident i f i cat i on 


This  specification  establishes  the  development,  test  and 
qualification  requirements  of  a  computer  program  identified  as 
the  Form  Processor,  referred  to  as  the  FP.  The  FP  is  one 
configuration  item  of  the  Integrated  Information  Support  System 
(IISS)  User  Interface  (UI)  and  consists  of  the  User  Interface 
Monitor  (UIM) ,  the  form  processor  callable  routines,  and  the 
window  management  processing. 

1 .2  Functional  Summary 

One  of  the  objectives  of  the  IISS  testbed  is  to  allow 
applications  to  be  run  from  a  wide  variety  of  terminals  using 
formatted  screens  for  input  and  output  of  application  data. 
Instead  of  the  application  programs  having  to  contain  terminal 
dependent  code  to  send/ receive  formatted  screens  to/ from  various 
types  of  terminals  and  to  perform  terminal  control  functions, 
the  program  may  use  the  set  of  callable  execution  time  routines 
of  the  FP. 

The  major  functions  of  the  FP  are: 

1.  Opening  and  displaying  a  form,  a  template 
defining  fields  and  their  attributes. 

2.  Placing  data  into  a  form  and/or  into  a  form  message 
line. 

3.  Sending  the  form  to  the  terminal. 

4.  Reading  the  data  from  the  terminal. 

5.  Stacking/replacing  forms  currently  open  for  the 
application  program. 

6.  IISS  Logon  Processing. 

7.  NTH  Message  Processing. 

8.  Window  Management  Processing. 
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SECTION  2 
DOCUMENTS 


2.1  Reference  Documents 


[1]  General  Electric  Co.,  I CAM  Integrated  Support 
System  ( IISS )  Test  Bed  System  Design 
Specification  (Draft) .  7  Feb  83,  SDS620 1 40000 . 

[2]  Structural  Dynamics  Research  Corporation, 

IISS  Form  Processor  User  Manual ,  1  November  1985. 

[3]  I CAM  Documentat i on  Standards ,  15  September  1983, 
IDS150120000C. 

[4]  Structural  Dynamics  Research  Corporation,  Report 
Writer  Development  Specification ,  DS  620144501  , 

1  November  1985. 

[5]  Structural  Dynamics  Research  Corporation,  Rapid 
Application  Generator  Development  Specification, 

DS  620144502  ,  1  November  1985. 

[6]  Structural  Dynamics  Research  Corporation,  Text 
Editor  Development  Specification,  DS  620144600B, 

1  November  1985. 

[7]  Structural  Dynamics  Research  Corporation,  Form 
Processor  Development  Specification ,  DS  620144200B, 

1  November  1985. 

[8]  Structural  Dynamics  Research  Corporation,  Appl i cat  ion 
Interface  Development  Specification,  DS  620144700  , 

1  November  1985 . 

[9]  Structural  Dynamics  Research  Corporation,  Forms 
Language  Compi ler  Development  Specification,  DS 
620144401 B ,  1  November  1985. 

[10]  Structural  Dynamics  Research  Corporation,  Forms 
Driven  Form  Editor  Development  Specification, 

DS  620144402B ,  1  November  1985. 
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[11]  Structural  Dynamics  Research  Corporation,  User 
Interface  Services  Development  Specification . 

DS  620144100B ,  1  November  1985. 

[12]  Structural  Dynamics  Research  Corporation,  Virtual 
Terminal  Development  Specification.  DS  620144300B, 
1  November  1985. 

2.2  Terms  and  Abbreviations 


American  Standard  Code  for  Information  Interchange : 

(ASCII),  the  character  set  defined  by  ANSI  X3.4  and  used  by  most 
computer  vendors . 

Appl i cat  ion  Int  erf ace :  (AI),  subset  of  the  IISS  User 
Interface  that  consists  of  the  callable  routines  that  are  linked 
with  applications  that  use  the  Form  Processor  or  Virtual 
Terminal.  The  AI  enables  applications  to  be  hosted  on  computers 
other  than  the  host  of  the  User  Interface. 

Application  Process :  (AP),  a  cohesive  unit  of  software  that 
can  be  initiated  as  a  unit  to  perform  some  function  or 
functions . 

Attribute :  field  characteristic  such  as  blinking, 
highlighted,  black,  etc.  and  various  other  combinations. 
Background  attributes  are  defined  for  forms  or  windows  only. 
Foreground  attributes  are  defined  for  items.  Attributes  may  be 
permanent,  i.e.,  they  remain  the  same  unless  changed  by  the 
application  program,  or  they  may  be  temporary,  i.e.,  they  remain 
in  effect  until  the  window  is  redisplayed. 

Common  Data  Model :  (CDM),  IISS  subsystem  that  describes 
common  data  application  process  formats,  form  definitions,  etc. 
of  the  IISS  and  includes  conceptual  schema,  external  schemas, 
internal  schemas,  and  schema  transformation  operators. 

Computer  Program  Configuration  Item:  (CPCI),  an  aggregation 
of  computer  programs  or  any  of  their  discrete  portions,  which 
satisfies  an  end-use  function. 

Conceptual  Schema :  (CS),  the  standard  definition  used  for 
all  data  in  the  CDM.  It  is  based  on  IDEF1  information 
model  ling. 

Current  Cursor  Pos i t ion :  the  position  of  the  cursor  before 
an  edit  command  or  function  is  issued  in  the  text  editor. 


DS  620144200B 
1  November  1985 


Cursor  Position:  the  position  of  the  cursor  after  any 
command  is  issued. 

Device  Drivers :  (DD),  software  modules  written  to  handle 

I/O  for  a  specific  kind  of  terminal .  The  modules  map  terminal 
specific  commands  and  data  to  a  neutral  format.  Device  Drivers 
are  part  of  the  UI  Virtual  Terminal . 

Display  List :  is  similar  to  the  open  list,  except  that  it 
contains  only  those  forms  that  have  been  added  to  the  screen  and 
are  currently  displayed  on  the  screen. 

Pi  splay  Size:  the  number  of  lines  used  in  the  edit  area 

Extended  Binary  Coded  Decimal  Interchange  Code :  (EBCDIC), 
the  character  set  used  by  a  few  computer  vendors  (notably  IBM) 
instead  of  ASCII . 

External  Schema :  (ES),  an  application's  view  of  the  CDM '  s 
conceptual  schema. 

Field :  two-dimensional  space  on  a  terminal  screen. 

Field  Pointer :  indicates  the  ITEM  which  contains  the 
current  cursor  position. 

Form :  structured  view  which  may  be  imposed  on  windows  or 
other  forms.  A  form  is  composed  of  fields.  These  fields  may  be 
defined  as  forms,  items,  and  windows. 

Form  Def ini t ion :  (FD).  forms  definition  language  after 
compilation.  It  is  read  at  runtime  by  the  Form  Processor. 

Forms  Def in i t i on  Language :  (FDL).  the  language  in  which 
electronic  forms  are  defined. 

Forms  Driven  Form  Ed i tor :  (FDFE),  subset  of  the  FE  which 
consists  of  a  forms  driven  application  used  to  create  Form 
Definition  files  interactively. 

Form  Edi tor :  (FE).  subset  of  the  IISS  User  Interface  that 
is  used  to  create  definitions  of  forms.  The  FE  consists  of  the 
Forms  Driven  Form  Editor  and  the  Forms  Language  Compiler. 

Form  Hierarchy :  a  graphic  representation  of  the  way  in 
which  forms,  items  and  windows  are  related  to  their  parent  form. 
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Forms  Language  Compi  ler  .  (FLAN),  .subset  of  the  FE  that 
consists  of  a  batch  process  that  accepts  a  series  of  forms 
definition  language  statements  and  produces  form  definition 
files  as  output. 

Form  Processor :  (FP),  subset  of  the  IISS  User  Interface 
that  consists  of  a  set  of  callable  execution  time  routines 
available  to  an  application  program  for  form  processing 

Fora  Processor  Text  Editor :  (FPTE).  subset  of  the  Form 
Processor  that  consists  of  software  modules  that  provide  text 
editing  capabilities  to  all  users  of  applications  that  use  the 
Form  Processor. 

Integrated  Information  Support  System :  (IISS),  a  test 
computing  environment  used  to  investigate,  demonstrate  and  test 
the  concepts  of  information  management  and  information 
integration  in  the  context  of  Aerospace  Manufacturing  The  IISS 
addresses  the  problems  of  integration  of  data  resident  on 
heterogeneous  data  bases  supported  by  heterogeneous  computers 
interconnected  via  a  Local  Area  Network. 

I  tern :  non -decomposable  area  of  a  form  in  which  hard-coded 
descriptive  text  may  be  placed  and  the  only  defined  areas  where 
user  data  may  be  input/output . 

Logical  Device :  a  conceptual  device  which  to  an  application 
is  indistinguishable  from  a  physical  device  and  is  then  mapped 
to  part  or  all  of  a  physical  device. 

Message :  descriptive  text  which  may  be  returned  in  the 
standard  message  line  on  the  terminal  screen  They  are  used  to 
warn  of  errors  or  provide  other  user  information 

Message  Line  a  line  on  the  terminal  screen  that  is  used  to 
display  messages 

Network  Transact i on  Manager :  ( NTH ) ,  IISS  subsystem  that 
performs  the  coordination,  communication  and  housekeeping 
functions  required  to  integrate  the  Application  Processes  and 
System  Services  resident  on  the  various  hosts  into  a  cohesive 
system 

Open  List  a  list  of  all  the  forms  that  have  been  and  are 
currently  open  for  an  application  process 
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Operating  System  (OS),  software  supplied  with  a  computer 
which  allows  it  to  supervise  its  own  operations  and  manage 
access  to  hardware  facilities  such  as  memory  and  peripherals. 

Page :  instance  of  forms  in  windows  that  are  created 
whenever  a  form  is  added  to  a  window. 

Pag i ng  and  Scrol ling:  a  method  which  allows  a  form  to 
contain  more  data  than  can  be  displayed  with  provisions  for 
viewing  any  portion  of  the  data  buffer 

Physical  Device  a  hardware  terminal 

Presentat 1  on  Schema :  (PS),  may  be  equivalent  to  a  form  It 

is  the  view  presented  to  the  user  of  the  application. 

Previous  Cursor  Pos i t i on :  the  position  of  the  cursor  when 
the  previous  edit  command  was  issued. 

Qual if ied  Name:  the  name  of  a  form,  item  or  window  preceded 
by  the  hierarchy  path  so  that  it  is  uniquely  identified 

Report  Def ini t ion  Language :  an  extension  of  the  Forms 
Definition  Language  that  includes  retrieval  and  calculation  of 
database  information  and  is  used  to  define  reports. 

Subform  a  form  that  is  used  within  another  form. 

User  Data:  data  which  is  either  input  by  the  user  or 
output  by  the  application  programs  to  items 

User  Interface  (UI).  IISS  subsystem  that  controls  the 
user  s  terminal  and  interfaces  with  the  rest  of  the  system  The 
UI  consists  of  two  major  subsystems  the  User  Interface 
Development  System  (UIDS)  and  the  User  Interface  Management 
System  (UIHS) 

User  Interface  Deve 1 opment  System :  (UIDS).  collection  of 
IISS  User  Interface  subsystems  that  are  used  by  applications 
programmers  as  they  develop  IISS  applications  The  UIDS 
includes  the  Form  Editor  and  the  Application  Generator 

User  Interface  Management  Sys  tern  (UIMS).  the  runtime  UI 
It  consists  of  the  Form  Processor,  Virtual  Terminal.  Application 
Interface,  the  User  Interface  Services  and  the  Text  Editor 
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User  Interface  Monitor :  (UIM).  part  of  the  Form  Processor 
that  handles  messaging  between  the  NTH  and  the  UI .  It  also 
provides  authorisation  checks  and  initiates  applications. 

User  Interf ace/ V i r tual  Terminal  Interface :  (UI/VTI), 
another  name  for  the  User  Interface 

Virtual  Terminal  :  ( VT )  .  subset  of  the  IISS  User  Interface 
that  performs  the  interfacing  between  different  terminals  and 
the  UI  This  is  done  by  defining  a  specific  set  of  terminal 
features  and  protocols  which  must  be  supported  by  the  UI 
software  which  constitutes  the  virtual  terminal  definition 
Specific  terminals  are  then  mapped  against  the  virtual  terminal 
software  by  specific  software  modules  written  for  each  type  of 
real  terminal  supported 

Virtual  Terminal  Interface  ( VTI ) ,  the  callable  interface 
to  the  VT 

Window :  dynamic  area  of  a  terminal  screen  on  which 
predefined  forms  may  be  placed  at  run  time 

Window  Manager :  a  facility  which  allows  the  following  to  be 
manipulated  size  and  location  of  windows,  the  device  on  which 
an  application  is  running,  the  position  of  a  form  within  a 
window  It  is  part  of  the  Form  Processor 


I 

i 


DS  620144200B 
1  November  1985 


SECTION  3 


REQUIREMENTS 


This  section  includes  functional  and  performance 
requirements  for  the  FP .  In  addition,  the  FP  interfaces  to 
other  IISS  Computer  Program  Configuration  Item  s  (CPCI  s)  are 
def ined 

3.1  Computer  Program  Definition 

The  Form  Processor  is  used  to  permit  an  application  to 
send / rece i ve  data  on  a  formatted  screen  without  having  the 
application  program  know  all  the  characteristics  of  the 
particular  terminal  being  used.  It  is  used  in  conjunction  with 
the  Virtual  Terminal 

When  used  in  the  IISS  environment,  the  application  programs 
use  the  Application  Interface  (AI)  to  create  the  appropriate 
messages  which  are  6ent  to  the  User  Interface  Monitor  (UIM)  of 
the  Form  Processor  by  way  of  the  Network  Transaction  Manager 
( NTM )  These  messages  are  then  decoded  into  the  appropriate 
Form  Processor  routines  The  routines  needing  to  input/output 
to  the  terminal  then  translate  the  request  into  the  correct 
Virtual  Terminal  commands.  If  the  Form  Processor  is  being  used 
on  a  one  computer  system,  the  application  program  would  be 
directly  interfacing  with  the  FP  callable  routines  instead  of 
the  Application  Interface  (AI)  which  generates  the  network 
formatted  message  The  Form  Processor  also  handles  window 
management  processing  which  requires  the  Form  Processor  to  be  in 
window  manager  mode  or  to  be  servicing  the  window  management 
f  ora 

3  1  1  System  Capacities 

The  system  capacities  required  to  run  the  FP  should  be 
defined  in  terms  of  additional  memory  requirements  for 
application  programs  using  the  Form  Processor  and  in  terms  of 
additional  timing  overhead  for  using  the  FP  to  send/receive  data 
to  from  the  terminal  The  limit  to  the  number  of  forms  being 
handled  by  the  FP  is  restricted  by  the  available  process  memory 

312  Interface  Requirements 

The  FP  interfaces  with  the  NTM  through  its  UIM.  with  the  AI 
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through  its  UIH  and  callable  routines,  and  with  the  VT  through 
the  VT  Form  Processor  callable  routines.  In  addition,  two 
different  methods  of  interfacing  to  an  AP  are  supported:  stand 
alone,  when  the  AP  may  link  directly  to  the  FP  and  no  NTM  is 
being  used,  or  the  IISS  environment,  when  the  AP  may  link  to  the 
Application  Interface  (AI)  routines.  In  either  environment,  the 
application  programs  use  the  exact  same  interface  to  the  FP 
Linking  to  the  FP  directly  is  simpler  and  more  efficient  than 
using  the  AI  but  does  not  support  the  use  of  an  NTM;  direct 
linking  is  most  useful  for  testing  purposes. 

The  UIM  part  of  the  FP  only  exists  when  the  NTM  is  being 
used  The  UIM  receives  the  message  formatted  by  the  AI  and 
translates  it  into  the  appropriate  FP  callable  routine  to  permit 
the  sending  or  receiving  of  the  forms  The  Form  Processor 
routines  then  interface  with  the  VT  by  translating  an 
application  request  into  the  appropriate  VT  command  when 
input  output  is  necessary 

3121  Interface  Block  Diagram 

The  structure  of  the  FP  interfaces  is  shown  in  Figure  3-1. 
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Figure  3-lb  FP  in  IISS  environment 


3. 1.2. 2  Detailed  Interface  Definition 


3. 1.2. 2.1  Application 


The  Fora  Processor  interface  for  IISS  applications  is  the 
set  of  callable  execution  tine  routines  available  for  an 
application  program  for  fora  processing.  These  routines  are 
defined  in  the  IISS  Form  Processor  User's  Manual.  The  FP 
routines  allow  application  programs  and  their  users  to 
communicate  through  predefined  forms  on  a  terminal .  Again  the 
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application  may  directly  interface  with  the  FP  through  the  FP 
routines  or  through  the  AI  routines.  In  either  case,  the 
calling  sequence  is  exactly  the  same. 

The  typical  order  of  events  in  an  application  program  using 
these  routines  is: 

1.  Initialize  form  processor. 

2 .  Open  forms . 

3.  Add  forms  to  windows. 

4.  Put  data  in  forms. 

5.  Put  data  in  message  line. 

6.  Send  screen  to  terminal. 

7.  Read  data  from  terminal. 

When  done  processing,  the  forms  should  be  closed,  then 

go  to  step  #10. 

8.  Remove  pages  that  will  not  be  displayed. 

9.  Replace  forms  if  necessary. 

To  continue  return  to  step  *3. 

10.  Terminate  form  processor. 

An  application  program  that  is  to  be  integrated  into  the 
IISS  and  that  uses  the  FP  routines  must  be  written  in  the  format 
that  includes  initialization  (INITFP)  and  termination  (TERMFP) 
calls  at  the  beginning  and  end  of  the  Procedure  Division  (COBOL) 
as  shown  in  Figure  3-2. 
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Figure  3-2 

COBOL  Procedure  Division 

3. 1.2. 2. 2  VT 

• 

The  FP  interfaces  with  the  VT  by  means  of  using  the  VT 
callable  routines.  Use  of  these  routines  is  only  necessary  when 
initializing  the  FP  (INITFP),  terminating  the  FP  (TERMFP) ,  and 
outputting  data  to  the  terminal  and  receiving  data  from  the 
terminal  (OISCR,  OUTSCR). 

3 . 1 . 2 . 2 . 3  FDL 


The  FP  interfaces  with  the  FDL  by  use  of  the  Forms 
Definition  File.  This  file  contains  the  binary  definition  of 
the  forms  that  the  FP  may  use.  It  simply  reads  in  a  form  by 
form  name  once  an  Open  Form  request  is  issued  for  a  given  form. 

3 .2  Detailed  Functional  Requirements 

3.2.1  General  Concepts 

The  following  sections  describe  some  concepts  that  are 
necessary  to  understand  before  specifying  the  detailed 
functional  requirements  of  the  FP . 
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3. 2. 1.1  User  Diagram  Examples 

The  diagram  Figure  3-3  illustrates  the  Form  Processor  data 
terminology  and  relates  these  data  types  to  one  smother  with 
respect  to  a  user's  view  of  a  terminal. 
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I  IFORM1  I 
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III 
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1  12  1 
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Figure  3-3  Data  Type  Hierarchy 


The  instances  of  the  various  data  types  in  Figure  3-3  can 
be  identified  by  using  qualified  names.  The  following  examples 
illustrate  this. 


" PSCREN. SCREEN. FORM 1 .WIND0W1 . FORM2 . 12; "  identifies  the  item 
named  12  in  the  form  named  FORM2  on  the  window  named 
WINDOW 1  on  the  form  named  F0RM1  on  the  window  named  SCREEN. 

"PSCREN. SCREEN < 99 > . F0RM1 .WIND0W1<98> .FORM2.il ; "  identifies 
the  item  named  II  in  the  form  named  F0RM2  on  page  98  of  the 
window  named  WIND0W1  on  the  form  named  F0RM1  on  page  99  of 
the  window  named  SCREEN. 

In  addition  to  qualified  names  that  identify  instances  of  a 
data  type,  simple  names  may  be  used  to  identify  a  form.  For 
example,  F0RM1 ,  identifies  a  particular  structured  view  but  does 
not  necessarily  imply  an  instance  of  a  page. 

3. 2. 1.2  Paging  and  Scrolling 

Paging  and  scrolling  refer  to  the  capability  of  displaying 
only  a  portion  of  the  total  information  associated  with  a 
particular  field.  To  implement  paging  and  scrolling,  it  is 
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necessary  to  allow  fields  to  be  array  structures,  i.  e.  a  field 
may  be  an  array  of  other  fields  or  even  an  array  of  arrays. 

The  difference  between  scrolling  and  paging  is  defined  as 
such:  scrolling  occurs  when  the  cursor  is  moved  by  one  element 
of  the  array  and  paging  occurs  when  the  cursor  is  moved  by  the 
number  of  elements  currently  displayed  on  the  screen.  Scrolling 
and  paging  may  be  performed  both  horizontally  and  vertically. 
Scrolling  and  paging  may  only  take  place  if  the  elements  being 
scrolled  or  paged  are  homogeneous.  For  example,  if  an  array  of 
windows  existed  and  each  window  did  not  contain  the  same  form, 
then  scrolling  and/or  paging  would  not  be  permitted  on  this 
array.  When  a  user  asks  for  scrolling  or  paging  in  a  specified 
direction,  the  form  processor  searches  the  display  list 
backwards  from  the  current  cursor  position  to  determine  which 
field  may  be  scrolled/paged  in  the  requested  direction. 

Each  array  structure  has  associated  with  it  two  pieces  of 
information  which  determined  what  part  of  the  array  is  currently 
displayed  on  the  screen:  the  first  element  of  the  array  to 
display  and  the  number  of  elements  of  the  array  to  display.  By 
using  this  information  the  form  processor  is  able  to  display  the 
correct  portion  of  the  array  as  the  scrolling  or  paging  is 
requested . 

3. 2. 1.3  Help  Forms 

Any  input  item  defined  for  a  form  may  have  a  help  form  or 
help  message  associated  with  it.  A  help  form  is  defined  as  a 
form  itself  but  is  used  only  when  the  "HELP”  key  is  pressed 
while  positioned  at  the  particular  field.  Upon  pressing  the 
"HELP"  key,  the  associated  help  form  or  message  is  displayed  to 
the  user . 

32.1.4  Terminal  Within  a  Terminal 

The  concept  of  terminal  within  a  terminal  refers  to  the  use 
of  windows.  When  the  application  program  displays  the  screen 
and  waits  for  input  from  the  screen,  it  provides  the  name  of  the 
window  to  be  used  for  inputting  data.  Everything  on  the  screen 
outside  this  window  is  automatically  guarded  except  for  the 
standard  message  line.  This  protection  means  the  user  may  only 
enter  data  in  the  specified  window. 
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3. 2. 1.5  Reserved  Keys 

Certain  virtual  terminal  function  keys  are  reserved  by  the 
FP  to  have  a  specific  meaning.  See  the  Terminal  Operator's 
Guide.  The  terminal  mapping  charts  in  Appendix  B  of  the 
Terminal  Operator's  Guide  list  the  actual  keys  that  map  to  the 
Form  Processor  functions  keys. 

3. 2. 1.6  ITEM  Values 

Every  item  defined  for  a  form  has  a  value  associated  with 
it.  This  can  be  a  constant  value  or  it  may  depend  on  the  value 
of  another  field  or  fields.  If  it  does  depend  on  another  field, 
it  is  referred  to  as  a  calculated  field  and  its  value  will  be 
recomputed  whenever  a  field  it  depends  on  is  changed.  The  value 
of  a  field  can  be  changed  in  three  ways:  by  the  application 
program  calling  PDATA ,  by  the  user  entering  data  from  the 
terminal  (if  it  is  an  input  field),  and  by  the  Form  Processor 
recomputing  it  when  one  of  the  fields  it  depends  on  changes 
(note  that  constant  values  are  never  recomputed). 

The  order  in  which  field  values  are  recomputed  is  undefined 
and  a  field  is  only  recomputed  once  per  display  so  using  one 
calculated  field  in  another  field's  value  is  not  supported. 

3. 2. 1.7  Window  Management 

3. 2. 1.7.1  User,  Device,  and  Application  Relationships 

Window  Management  processing  should  allow  the  following 
mappings : 

1)  A  single  user  mapped  to  one  logical  device  and  one 
appl i cat  ion . 

2)  A  single  user  mapped  to  multiple  devices  and  one  application. 

3)  A  single  user  mapped  to  one  device  and  multiple  applications. 

4)  An  application  without  a  user  mapped  to  multiple  devices. 

Appendix  A  provides  figures  which  demonstrate  these 
mappings . 
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3. 2. 1.7. 2  Application  Functionality 

An  application  needs  to  be  able  to  control  the  allocation 
of  logical  devices.  It  may  do  so  by  using  the  following  Form 
Processor  routines: 

Inquire  Logical  Device  ( INQLDV )  -  Allows  the  application  to 
determine  the  logical  device  number  it  is  currently  using. 

Open  Logical  Device  ( OPNLDV )  -  Provides  the  application  with  a 
new  device. 

Change  Logical  Device  ( CHGLDV )  -  Allows  the  application  to 
change  which  device  it  is  using. 

Close  Logical  Device  (CLSLDV)  -  Allows  the  application  to  remove 
this  device  when  it  no  longer  is  needed. 

3 . 2 . 1 . 7 . 3  Window  Manager  Mode 

Window  Manager  Mode  is  another  mode  of  the  Form  Processor. 
It  allows  a  user  to  manipulate  the  windows  that  are  displayed  on 
the  screen  while  a  single  application  or  several  applications 
are  running.  The  following  functions  which  are  described  in  the 
Terminal  Operator's  Guide  are  provided  for  the  user  when  in 
Window  Manager  Mode: 

3. 2. 1.7. 3.1  Selection 

Selecting  a  window  allow  the  user  to  change  the  size  and 
location  and  scroll  information.  This  also  puts  the  window  on 
the  top  of  the  stack  so  that  the  user  can  view  it  completely. 

All  the  following  Window  Manager  mode  funcitons  require  that  the 
window  be  selected  first. 

To  select  a  window,  the  user  positions  the  cursor  within 
the  window  and  presses  the  SELECT  function  key. 

3. 2. 1.7. 3. 2  Scrolling 

The  data  being  displayed  in  a  window  does  not  have  to  fit 
within  the  window  completely;  therefore  scrolling  keys  are 
necessary  to  move  the  display  of  data  around  to  position 
different  parts  of  the  data  in  the  window. 

Scrolling  may  be  done  up,  down,  left,  or  right  by 
positioning  the  cursor  on  the  data  and  pressing  the  appropriate 
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scroll  key.  That  position  on  the  data  is  then  moved  to  the  edge 
of  the  window  in  the  appropriate  direction. 

3. 2. 1.7. 3. 3  Size 

After  selecting  the  window,  the  cursor  is  positioned  by 
the  user  to  where  the  user  wants  the  lower  right-hand  corner  of 
the  window  to  be,  and  then  the  SIZE  function  key  is  pressed. 

3. 2. 1.7. 3. 4  Location 

To  move  the  selected  window,  the  user  positions  the  cursor 
to  where  the  user  wants  the  upper  left-hand  corner  of  the  window 
to  be  and  presses  the  LOCATION  function  key. 

3.2. 1 .7.3.5  Restore 

A  user  restores  a  selected  window  to  its  previous  position 
on  the  stack  by  pressing  the  RESTORE  function  key. 

3. 2. 1.7. 3. 6  Function 

To  display  the  function  screen  so  a  user  can  request  a 
different  function  to  begin  processing,  the  user  presses  the 
FUNCTION  key. 

3. 2. 1.7. 3. 7  Appl i cat  ion 

To  select  the  initial  window  of  the  application,  the  user 
positions  the  cursor  anywhere  within  the  application's  display 
area  and  presses  the  APPLICATION  function  key. 

3. 2. 1.7. 3. 8  Home  View 

To  return  a  form  that  has  previously  been  scrolled  back  to 
its  original  position  in  the  window,  the  user  presses  the  HOME 
VIEW  function  key. 

3. 2. 1.7. 4  Window  Manager  Information  Form 

Some  operations  that  can  be  performed  on  windows  cannot  be 
done  in  keypad  mode,  such  as  changing  the  precedence  of  the 
applications  being  displayed  or  changing  the  device  where  the 
window  is  being  displayed.  For  these  operations,  the  WINDOW 
function  may  be  entered  on  the  IISS  Function  form.  A  figure  of 
this  form  may  be  found  in  Appendix  B.  This  form  may  be  used  by 
the  user  to  perform  the  following  operations: 
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3.21.7.4.1  Review  Windows 

The  information  displayed  includes:  the  device  on  which  the 
application  is  displayed,  the  order  in  which  applications  are 
stacked  on  the  screen,  and  the  location,  size  and  viewport 
offset  of  the  windows  Viewport  is  the  offset  from  the  upper 
left-hand  corner  of  the  logical  screen  to  the  upper  left-hand 
corner  of  the  physical  screen. 

3.2.1.74.2  Change  Devi ce 

The  device  name,  as  used  and  recognized  by  the  NTH .  of  each 
application  that  is  running  on  the  terminal  is  displayed  on  the 
form  The  user  can  change  this  name  and  move  the  initial  window 
of  any  application  to  any  other  device  that  is  hardwired  to  the 
system 

3.21.74.3  Change  Window  Si ze 

The  size  of  all  windows  is  displayed  on  the  form  The  user 
can  change  the  size  of  any  window.  This  includes  giving 
dimension  to  a  window  with  0,0  size  that  has  been  hidden  and  so 
restore  its  visibility. 

3 . 2 . 1 . 7 . 4 . 4  Change  Location 

The  location  of  the  top  left  row  and  column  of  the  window 
relative  to  the  upper  left  corner  of  the  parent  window  is 
displayed.  The  user  can  change  these  values  and  so  change  the 
relative  position  of  the  window. 

3. 2. 1.7. 4. 5  Change  Prjioi^ity 

The  order  in  which  the  windows  are  stacked  on  the  screen  is 
displayed  on  the  form  as  the  priority  number  of  the  window 
Thus  the  last  application  to  be  initiated  has  a  priority  number 
of  1  and  is  on  top  of  the  stack  of  initial  windows  and  is 
totally  visible.  The  user  can  change  this  number  to  give  any 
application  top  priority  This  has  the  same  effect  as 
selecting  a  window  interactively  using  the  SELECT  function  of 
the  Window  Manger  Mode 

3. 2. 1.8  User  Interface  Monitor  Processing 

The  User  Interface  Monitor  of  the  Form  Processor  handles 
presenting  and  processing  the  IISS  Logon  Screen  and  the  IISS 
Function  Form.  It  also  handles  sending  and  receiving  NTM 
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messages  fromto  the  1ISS  applications  for  their  Form  Processor 
calls  and  from/ to  the  Virtual  Terminal  Device  Driver 

32  2  External  Data  View 

3  221  IDEF1  Hodel 

The  IDEF1  model  translates  the  data  types  that  are  relevant 
from  an  applications  requirement  for  forms  processing  into  a 
conceptual  view  The  following  model  in  Figure  3-4a  defines  the 
entities  and  relationships  for  the  FP  window  management  data 
The  model  in  Figure  3-4b  defines  the  entities  and  relationships 
for  the  FP  form  data  The  following  entities 

PS  ES  Map , 

PS  Store  data  type , 

PS  Control  data  type. 

PS  Control  domain . 

PS  Store  domain,  and 
(data  item) 

are  future  considerations  for  CDM  Integration 


r - 
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s  on 


user 


uses 


AP 
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|  ahusit.nl  device  name 
i  win  channel  m 
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i 

physical 
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device  i 
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!  may  be 
|  used  lot 
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device  id 
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logical  device 


Figure  3-4a  IDEF1  Model  of  Form  Processor 
Window  Management  Data 
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3.2.22  Appl icat i on  Data  Schema 

The  following  table  shows  the  relationships  between  the 
types  of  data  and  the  functions  on  them.  This  table  is  defined 
in  terms  of  the  application  views  data  usage  Internal  changes 
to  these  data  resulting  from  the  use  of  these  functions  is 
described  by  the  internal  data  schema 

The  following  abbreviations  are  used  for  purposes  of  this 
table : 


n  -  name 
pn  -  path  name 
#  -  page  number 

v  -  value 

a  -  array  (indicates  this  may  be  an  array  of  the 
specified  data  type) 


I(n) 

I(pn) 

I(#) 

I(v) 

0(1) 

0(n) 

0(pn) 

0(#) 

0(  v) 

I ( pn ) * 


Input  the  name . 

Input  the  path  name . 

Input  page  number . 

Input  the  value. 

Output  the  length. 

Output  the  name . 

Output  the  path  name . 

Ouput  page  number . 

Output  the  value  of  the  instance  of  the  data  type. 
For  a  function  which  may  input  different  types  of 
data,  one  of  these  types  is  Input  to  the  function 


The  Form  Processor  routines  CHGLDV,  CLSLDV,  INQLDV,  and 
OPNLDV  are  not  in  this  table  because  they  operate  on  logical 
devices  only. 
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OPNFRM 

I  ( n  ) 

OUTSCR 

I(pn) 

PDATA 

I  (  pna  )  * 

I ( pna ) * 

I(  V  ) 

PARFQN 

I ( pn )  * 

I ( pna ) * 

I (pna)* 

0(n)  * 

0(  n )  * 

0(  n  )  * 

PMSGLC 

I  ( n ) 

-CONTINUED- 


3-16 


>V-  s.'s  '/;.  ;/y  - 


v.v.v. v'  -.  s^. 
^  -s  Ts,  :/y^.  -V.  ^. 


DS  620144200B 
1  November  1985 


U  A 

S  T 

E  NT 


V 

R 

E  R 

I 

S  I 

N 

P 

F 

I 

D 

S  B 

D 

A 

0 

T 

A 

A  U 

0 

G 

R 

E 

T 

G  T 

W 

E 

M 

M 

A 

E  E 

Funct l on 

PMSGLS 

I(v) 

PUTATT 

I(pn) 

I  ( n ) 

PUTBAK 

I  (  pn  )  • 

I(pn)* 

I(n) 

PUTCUR 

I ( pn  )  * 

I  ( pn  )  • 

I ( pn ) * 

RMVPAG 

I(pn ) 

I(*) 

RPLFRM 

I  ( pn  ) 

i  ( * ) 

TTnl 

TERMFP 

Figure  3-5  Table  of  Application  Data  Changes 
323  Interna 1  Data  View 

The  following  sections  describe  the  internal  data  that  is 
maintained  by  the  FP  for  the  application  program.  The 
representation  of  this  internal  data  does  not  necessarily  imply 
its  implementation  but  suggests  the  relationships  between  the 
various  types  of  data  and  the  operations  performed  on  the  data. 
Figure  3-6  shows  the  basic  elements  of  the  Form  Processor. 

323  1  Open  List 

The  Open  List  is  a  list  of  all  the  forms  that  are  currently 
open  for  an  application  process.  Figure  3-8  shows  the  Open  List 
after  FP  initialization  Figure  3-9  shows  the  Open  List  after 
opening  form  FI  containing  Form  F2 .  Figure  3-10  shows  the  Open 
List  after  form  FI  is  added  to  the  window  SCREEN.  Note  the  links 
in  the  next  use  field  between  the  Open  List  and  the  display 
list 
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3. 2. 3. 2  Display  List 

The  Display  list  is  similar  to  the  open  list  except  it 
contains  all  forms  that  have  been  added  to  the  screen  and  are 
currently  displayed  on  the  screen.  Figure  3-8  shows  the  Display 
List  after  FP  initialization.  Figure  3-11  shows  the  Display 
List  after  the  form  FI  has  been  added  to  the  window  SCREEN. 

Note  the  links  in  the  open  pointer  field  between  the  Open  List 
and  the  Display  List  after  the  form  FI  is  added  to  the  window 
SCREEN . 

3.2. 3. 3  Window  Management  Lists 

Window  management  processing  is  based  on  operations  on  the 
following  lists.  Figure  3-7  illustrates  elements  of  these 
lists. 

3. 2. 3. 3.1  User  List 

This  list  contains  all  User  Interface  users.  Each  user 
list  element  has  an  application  list  and  a  physical  device  list 
associated  with  it. 

3. 2. 3. 3. 2  Physical  Device  List 

This  list  contains  all  User  Interface  physical  devices. 

Each  physical  device  list  element  has  associated  with  it  the 
user  and  a  list  of  all  logical  devices  for  the  user. 

3. 2. 3. 3. 3  Application  List 

This  list  contains  all  User  Interface  applications.  Each 
application  list  element  has  associated  with  it  a  user  and  that 
user's  list  of  applications  and  a  list  of  logical  devices  being 
used  by  the  application. 

3.2. 3. 3.4  Logical  Device  List 

This  list  contains  all  User  Interface  currently  opened 
log  ical  devices.  Associated  with  a  logical  device  list  element 
is  an  application,  a  user,  an  open  list,  and  a  display  list. 
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3. 2. 3. 4  Internal  Data  Schema 

The  following  table  in  Figure  3-12  defines  the 
relationships  among  the  data  and  the  operations  on  this  data 
from  an  internal  view  of  the  FP  functions.  The  following 
abbreviations  are  used  in  the  table: 

C  -  Create 
D  -  Delete 
E  -  Exam i ne 
M  -  May 
R  -  Retrieve 
U  -  Update 
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Figure  3-13  Error  Message  Mapping, 
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3.2.4  Functional  Processing 

The  calling  sequence,  description  and  parameter 
descriptions  found  in  the  Form  Processor  User  Manual  describe  in 
detail  each  routine's  input,  output,  and  processing.  Figure 
3-13  describes  the  possible  error  conditions  that  may  result 
from  using  the  Form  Processor  routines. 

33  Special  Requirements 

3.3.1  P r ogrammi ng  Methods 

The  FP  shall  be  programmed  using  structured  design  and  care 
shall  be  taken  to  insure  portability  of  the  the  FP  code  with 
minimum  effort  Basic  programming  standards  for  readability  and 
ease  of  debugging  shall  be  followed 

332  Expand l bi 1 l ty 

Since  the  FP  has  been  designed  as  a  set  of  interface 
routines,  new  functionality  may  be  added  by  simply  adding  new 
interface  routines.  The  interface  between  the  UIM  of  the  Form 
Processor  and  the  AI  would  simply  be  changed  to  add  a  new 
interface  routine  which  the  UIM  of  the  Form  Processor  would  be 
capable  of  calling  The  operations  on  the  internal  data 
structures:  the  Open  List,  the  Display  List,  and  the  Window 
Management  Lists  are  abstracted  into  separate  functions  which 
may  easily  be  used  by  any  new  interface  routines  added  to  the 
FP 

3  4  H uman  Per f o r man  ce 

Performance  requirements  for  the  FP  have  not  yet  been 
determined.  These  requirements  should  included  a  statement  of 
response  time  lor  displaying  and  entering  a  screen  and  the  ease 
of  use  of  the  features  such  as  scro 1 1 l ng/ pagi ng  and  reserved 
keys  . 

3.5  Data  Base  Requirements 

The  data  base  requirements  listed  here  are  in  addition  to 
those  outlined  in  the  Detailed  Functional  Requirements  section. 
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3.5.1  Sources  and  Types  of  Input 

3. 5. 1.1  FP  Processing  Data 

The  FP  requires  a  data  structure  containing  the  current 
status  of  processing  and  also  information  about  the  various 
attributes  allowed  for  the  form  fields. 

The  following  information  is  maintained  by  the  FP : 

Location  of  Open  List 
Location  of  Display  List 
Location  of  Application  List 
Location  of  User  List 
Location  of  Physical  Device  List 
Current  Logical  Device 
Window  Identification  Table 
NTM  Channel  Table 

3. 5. 1.2  FPL  Form  Description  File 

The  FP  reads  records  that  are  created  by  the  FDL  compiler 
These  records  define  the  forms  that  are  opened  by  the 
application  program.  The  FP  reads  one  file  per  form.  This  file 
contains  records  defining  the  form  version,  the  form,  the  text 
on  the  form,  and  the  fields  within  the  form.  A  detailed  layout 
of  these  records  may  be  found  in  the  Forms  Definition  Language 
Compiler  Development  Specification. 

3.5.2  Destinations  and  Types  of  Output 
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3.5.3  Internal  Tables  and  Parameters 


The  initial  attribute  definition  table  is  defined  at  FP 
initialization.  The  following  attributes  are  defined: 

TEXT 

INPUT 

OUTPUT 

ERROR 

BLACK 

WHITE 

XPARNT  (transparent) 

HIDDEN 

GUARDED 


At  initialization  of  the  FP,  the  Attribute  Map  List  is 
built  which  is  a  list  of  all  these  valid  attributes. 


3-32 


'f.rt, 


///'•/.’//.‘A’ 

-  -V  -  ‘  .!■  ■ 


A tVfcAil A A Jkh. mAM*) 


m 


•ffij 


DS  620144200B 
1  November  1985 


SECTION  4 


QUALITY  ASSURANCE  PROVISIONS 


4 . 1  Introduction  and  Definitions 

The  FP  is  tested  using  the  following  tests: 

Computer  programming  test  and  evaluation.  This  testing 
primarily  involves  testing  all  the  FP  interface  routines  and 
internal  functions  for  correct  processing  and  output. 

System  test.  This  testing  involves  testing  all  the  FP 
interface  routines  and  internal  functions  within  the  integrated 
system . 

4.2  Computer  Programming  Test  and  Evaluation 

The  test  developed  for  the  FP  consists  of  another  computer 
program  which  uses  the  FP  interfaces  routines  by  an  application 
program.  Every  FP  interface  routine  is  exercised  directly  by 
the  computer  test  program  and  every  internal  function  is 
indirectly  exercised  by  the  computer  test  program.  Variations 
on  the  computer  test  program  may  be  provided  by  user  interaction 
with  the  computer  test  program. 

The  same  computer  test  program  is  run  to  test  the  FP  during 
the  system  test  process  with  the  other  components  of  the  IISS. 


V  *  - 
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SECTION  5 

PREPARATION  FOR  DELIVERY 


The  implementation  site  for  the  constructed  software  is  the 
ICAM  Integrated  Support  System  (IISS)  Test  Bed  site  located  in 
Schenectady,  NY.  The  software  associated  with  each  FP  CPCI 
release  is  delivered  on  a  media  which  is  compatible  with  the 
IISS  Test  Bed.  The  release  is  clearly  identified  and  includes 
instructions  on  procedures  to  be  followed  for  installation  of 
the  release. 
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APPENDIX  A 

WINDOW  MANAGEMENT  MAPPINGS 


Figure  A-l  Single  User,  Single  Device,  Single  Application 


Figure  A-2  Single  User,  Multiple  Devices.  Single  Application 
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